Design Comments: This identification attribute supports capture of a healthcare identifier specific to the client. This identifier may be assigned jurisdictionally or by care facility.

UsageNotes: At least 1 client identifier must be present in the message

Rationale: Mandatory attribute supports unique identification of the client.

Design Comments: Indicates the status of the Client role (e.g. Active)

Rationale: Populated attribute supports the identification of the client

Design Comments: An interval of time specifying the period during which this record in a client registry is in effect, if such time limit is applicable and known

Rationale: Required attribute supports the identification of the client

Design Comments: x_NormalRestrictedTabooConfidentialityKind

A code that controls the disclosure of information about this patient encounter.

UsageNotes: Data in the EHR may at some point (and in some jurisdictions) be accessed directly by patients. Some health information may be deemed inappropriate for direct access by patients and requires interpretation by a clinician (e.g. prescription of placebos, analysis of certain psychiatric conditions, etc) Even where direct access by patient is not provided, there may need to be guidance to other providers viewing the record where care should be used in disclosing information to the patient. Non-clinical data (e.g. demographics) may need to be flagged as not for disclosure to patient and or next of kin. There may be professional policy and or legislative guidelines about when/if records may be flagged as not for direct disclosure.

Rationale: Populated attribute supports the business requirement to provide restricted access where required

Design Comments: The Person class contains identifying and demographic data elements for the focal person similar to those in the HL7 v2.x PID segment such as name, gender, date of birth, deceased indicator and time.

Rationale: Provides additional demographic data elements for the focal class IdentifiedEntity

Design Comments: Associates the IDENT role with a required observation which indicates the confidence value of the returned record(s).

Design Comments: Name(s) for the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: Provides information about telecom

Rationale: Populated attribute supports the identification of the client

Design Comments: Gender of the Client, this is not to be confused with Clinical Gender of a client. Administrative Gender is typically restricted to Male (M), Female (F) or Undifferentiated (U)

Rationale: Populated attribute supports the identification of the client

Design Comments: Date of birth of the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: An indication that the client is deceased. Appropriate business process/function will need to be employed to ensure that validation or verification of the death event has been established prior to populating the message.

Rationale: Required attribute supports the identification of the client

Design Comments: The date and time that a client's death occurred.

Rationale: Required attribute supports verification of death from official source such as Vital Statistics.

Design Comments: An indication as to whether the client is part of a multiple birth.

Rationale: Required attribute supports the identification of the client

Design Comments: The order in which this client was born if part of a multiple birth.

Rationale: Required attribute supports the identification of the client

Design Comments: Address(es) of the Client

Rationale: Populated attribute supports the identification of the client

Design Comments: Identifiers used for the focal person by other organizations are sent in the OtherIDs class. The other organization can be sent in the E_Organization Entity Class

Rationale: Provides the ability to capture additional client identifiers that are not healthcare specific

Design Comments: Associations between persons in the Person Registry, such as spouse or parent, can be sent in a PersonalRelationship class. The exact nature of a association is described by the code attribute with a value drawn from the PersonalRelationshipRoleType domain. Most associations can be represented in either of two ways depending on who is the player and who is the scoper. For example, the association between a father and his daughter can be represented by a code of "father" where the parent is the player and the child is the scoper, or by a code of "daughter" where the child is the player and the parent is the scoper.

Rationale: Supports the business requirement to capture additional information about the Identified Client's Next of Kin

Design Comments: Information about what language(s) should be used to communicate with the focal person can be sent in the LanguageCommunication class.

Rationale: Supports the business requirement to identify languages used by client for the purposes of communication

Design Comments: Other non-healthcare identifiers for the Client (e.g. Drivers License, RCMP, DND, Social Insurance Number)

Rationale: Populated attribute supports the identification of the client

Design Comments: A pan Canadian code further specifying the kind of Role such as Drivers License, RCMP, DND, Social Insurance Number

Rationale: Populated attribute supports the identification of the client

Design Comments: The Organization responsible for issuing the Other ID identified in the OtherIDs Role Class

Rationale: Supports the requirement to supply additional information regarding the assigning Organization of the OtherID

Design Comments: Unique identifier for the organization that assigned the non-healthcare identifier for the client.

Rationale: Mandatory attribute supports the identification of the organization assigning the identifier to the client

Design Comments: A name for the non-healthcare organization

Rationale: Populated attribute supports the identification of the organization assigning the identifier to the client

Design Comments: A code further specifying the kind of Role such as Mother, Father, Natural Parent or Step Parent

Rationale: Mandatory attribute that supports understanding the relationship between the client and the Next of Kin

Design Comments: The Parent Person class can send the person that is legally responsible for the care and management of the focal person. If the relationship (e.g., parent, spouse, unrelated friend) of the guardian to the focal person is of interest then a PersonalRelationship with the same persons as player and scoper should also be sent.

Rationale: Supports the business requirement to capture identification and demographic information regarding the Identified Client's Next of Kin

Design Comments: A unique identifier for the next of kin

Rationale: Populated attribute supports the identification of the next of kin and allows for the use of null flavours when the identifier is not known or available.

Design Comments: A name for the next of kin

Rationale: Required attribute supports the identification of the next of kin

Design Comments: A code indicating the language of communication

Rationale: Mandatory attribute conveying the expected language message elements are to be transmitted in

Design Comments: Indicates the preferred language for all communications.

Rationale: Required attribute that supports the business requirement to indicate the preferred language for all communications.

Design Comments: Each returned IdentifiedPerson can have an associated ObservationEvent reporting the confidence value (degree of certainty) and the name of the matching algorithm that resulted in that record's inclusion in the result set.

Rationale: Supports the business requirement to provide a confidence value associated with the identifiedEntity returned in the response distinguishes these different representations.

Design Comments: Supports the business requirement to identify type of confidence matching used i.e. the code would be the name for the algorithm for the confidence value

Rationale: Mandatory attribute supports confident identification of intended client

Design Comments: A real number value indicating the confidence of the query with regard to finding the intended target client i.e. the value would be the computed confidence value.

Rationale: Required attribute to provide information about success of query